Skip to content

Change input parameters of apify-get-dataset-items - #8

Merged
oleksandravalko merged 1 commit into
masterfrom
feat/6-apify-get-dataset-items
Sep 4, 2025
Merged

Change input parameters of apify-get-dataset-items#8
oleksandravalko merged 1 commit into
masterfrom
feat/6-apify-get-dataset-items

Conversation

@oleksandravalko

Copy link
Copy Markdown

WHY => https://github.com/apify/integrations-team/issues/6

On top of the required changes, I tweaked the function, which gets the list of datasets. The default behaviour of an API is to return only named datasets, while users can not just insert the ID manually in PD UI. So the users are unable to retrieve items of unnamed datasets, as long as they are not connected to any previous steps of the workflow. Let me know if this change is welcome.
image

@oleksandravalko oleksandravalko self-assigned this Sep 3, 2025

@drobnikj drobnikj left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

@oleksandravalko
oleksandravalko merged commit 185efb1 into master Sep 4, 2025
6 of 7 checks passed
matyascimbulka added a commit that referenced this pull request Sep 24, 2025
* feat(apify): Show list of built tags in actor run action

* feat(apify): Allow selecting actor search source for run Actor action and change how Actor or task name is displayed

* feat(apif): Remove wait for finish prop in run Actor action

* fix(apify): Fix PR issues

* fix(apif): Fix PR issues

* fix(scrape-single-url): return the only dataset item after the run is finished (#3)

* fix(scrape-single-url): return the only dataset item after the run is finished

* fix(scrape-single-url): version up

* fix(scrape-single-url): version up

* fix(scrape-single-url): version up

* fix(scrape-single-url): introduce a job status constant, expand a list of terminal statuses to stop the loop

* fix(scrape-single-url): import constants from package, decrease delay in between calls

* Migrate to use Apify client (#6)

* feat(apify): Replace Axios with Apify client

* fix(general): adding custom headers to client()=> preserve whole config to be passed to Axios later

* feat(general): add linter script

* fix(apify-get-dataset-items): a function for getting items and parsing of a result

* fix(apify-run-actor): working sync and async, dynamic input schema injection, KVS output retrieval tested only string

* fix(general): change maxResults for limit as an input field

* fix(run-task-sync): move items retrieval to the component, add waitSecs determined by input or plan to prevent blunt timeout error, have the item retrieval logic be connected to run status, clean return value

* fix(apify-scrape-single-url): incorporate timeouts, rework the whole API interaction logic

* fix(apify-set-key-value-store-record): detection of content type, fixed API interaction

* fix(apify-scrape-single-url): remove waiting timeout, return only dataset item, remove extra input fields connected to WCC run

* fix(apify-run-actor): success message

* fix(apify-run-task-synchronously): remove waiting for run to finish timeout

* fix(app): remove paidPlan input filed config

---------

Co-authored-by: Matyas Cimbulka <matyas.cimbulka@apify.com>

* fix(apify-get-dataset-items) 6: change input parameters (#8)

* chore(apify): Bump component versions

* chore: Sync upstream repo (#9)

* feat(apify): Prefill values from the input schema (#7)

* Revert "chore: Sync upstream repo (#9)"

This reverts commit cd804ba.

* Revert "chore(apify): Bump component versions"

This reverts commit 6040822 which for some reason bumped version of the wrong components.

* fix(apify): Fix build tag

* fix(apify): Address issues in run task synchronously action

* feat(apify): Add default crawler type to scrape single url

* fix(apify): Address issues from PR

* chore(apify): Change component versions

* fix(apify): Fix run Actor action

* fix(apify): Fix run get dataset items action

* fix(apify): Fix typos for PR

---------

Co-authored-by: Oleksandra Valko <oleksandra.valko@apify.com>
drobnikj pushed a commit that referenced this pull request Sep 3, 2026
…1826)

* feat(dappier): AI-optimized Dappier action set for MCP (real-time search, recommendations, analytics)

Initial AI-optimized Dappier components for the MCP tool surface, covering
issue PipedreamHQ#21660 (real-time web search, AI content recommendations, data-model
querying) plus the four Analytics API endpoints. Iterated against the MCP
eval suite (evals/dappier) — 9/10 green on Sonnet 5 (trials: 1); the one
failure is an upstream HTTP 500 on POST /app/v2/search, not a component
defect. agent-audit: 100/100.

- search-real-time-data (new, 0.0.1): real-time web/data search via a Dappier
  AI model (am_ id); returns a synthesized answer. Eval #9 passes.
- get-ai-recommendations (new, 0.0.1): AI-ranked content recommendations for a
  data model (dm_ id); optional additive `fields` projection trims large
  article payloads. Eval #10 blocked by an upstream 500 (server-side).
- get-ask-ai-analytics (new, 0.0.1): aggregate Ask AI widget analytics. Evals #1/#4/#5 pass.
- get-ask-ai-logs (new, 0.0.1): raw Ask AI conversation logs with page/limit
  pagination + paging guidance. Evals #2/#6 pass.
- get-sponsored-conversations-analytics (new, 0.0.1): sponsored-conversation
  (ad campaign) analytics. Eval #7 passes.
- get-session-intelligence (new, 0.0.1): session intent/topic breakdowns. Evals #3/#8 pass.
- dappier.app.mjs: shared analytics prop definitions + GET request methods.
- common/utils.mjs: validateDateRange (365-day cap) + pluckFields projection helper.
- common/constants.mjs: analytics interaction types, range + page-size bounds.

App package.json bumped 0.0.1 -> 0.1.0 (minor -- new actions).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* fix(dappier): add trailing newline to package.json (eol-last)

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* fix(dappier): address review — numArticlesRef max, own-prop projection, date default wording

- get-ai-recommendations: numArticlesRef description said max 1000 but schema is max 100; corrected the doc.
- common/utils.mjs: pluckFields now uses Object.hasOwn so a requested field name that collides with an inherited prop (e.g. toString) is not copied; own result fields still are.
- dappier.app.mjs: reworded startDate default from the brittle/off-by-one '7 days before today' to 'the last 7 days (UTC), i.e. today and the six prior days', matching observed API behavior.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* fix(dappier): resolve one-sided analytics date windows before sending

Verified against the live API: omitting either start_date or end_date makes
Dappier reset BOTH bounds to its default trailing-7-day window, silently
discarding the bound the caller supplied — so a one-sided range returned the
wrong period. resolveDateRange() now fills the missing bound (missing end ->
today UTC; missing start -> 6 days before the end) and always sends both, so a
supplied bound is honored; both-omitted still defers to the API default. All
four analytics actions use it; start/end prop docs updated.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* fix(dappier): match analytics date-range cap to the API (inclusive days)

Probed the live API: it accepts a 364-day start/end difference (365 inclusive
days) and returns 400 at a 365-day difference (366 inclusive days).
validateDateRange used '> 365 days difference', so a 365-day-difference window
slipped past the fail-fast and hit a raw API 400. Now counts inclusive days
(difference + 1) and caps at 365, matching the API exactly.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* docs(dappier): note session_intelligence wrapper in get-session-intelligence description

The API nests all six breakdowns under a single top-level `session_intelligence`
object (verified live). The description listed them as if they were root keys,
so an agent would look for them at the root and miss the `session_intelligence.`
prefix. Description-only; no behavior change.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* docs(dappier): use camelCase widgetId in session-intelligence example

The example told the agent to pass `widget_id`, but the input prop is
`widgetId` (run() maps it to the `widget_id` query param). Match the example
to the prop the agent actually sets. Description-only.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* docs(dappier): use camelCase prop names in remaining action examples

Same fix as get-session-intelligence, applied to the sibling descriptions:
the agent-facing 'Example:' hints used API param names (start_date, end_date,
campaign_id, data_model_id) instead of the camelCase input props (startDate,
endDate, campaignId, dataModelId). API-mapping mentions stay snake_case.
Description-only; no behavior change.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* docs(dappier): camelCase input-guidance for model-id props

The 'Provide a ...' input guidance used API param names — get-ai-recommendations
said 'Provide a data_model_id' (prop is dataModelId) and search-real-time-data
said 'Provide an ai_model_id' (prop is aiModelId). Use the camelCase input keys;
snake_case is retained only where describing the API request mapping
(query param / path template). Description-only.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* Adding missing dependencies field

---------

Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Co-authored-by: GTFalcao <gtfalcao96@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants